-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Actor State TTL #1164
Actor State TTL #1164
Conversation
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
@@ -57,7 +57,7 @@ internal class DaprHttpInteractor : IDaprInteractor | |||
this.httpClient.Timeout = requestTimeout ?? this.httpClient.Timeout; | |||
} | |||
|
|||
public async Task<string> GetStateAsync(string actorType, string actorId, string keyName, CancellationToken cancellationToken = default) | |||
public async Task<ActorStateResponse<string>> GetStateAsync(string actorType, string actorId, string keyName, CancellationToken cancellationToken = default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to keep ActorStateResponse
as an internal type. How do we keep complication happy with this constraint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philliphoff any ideas here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ActorStateResponse
is already internal
, no, or are you referring to the fact that this method is public
? IDaprHttpInteractor
and DaprHttpInteractor
are already internal
types, so nothing of them can be seen outside the SDK. The public
on the method only applies to other types within the SDK. (Method visibility is always masked by visibility of the underlying type.)
@@ -35,17 +36,17 @@ internal ActorStateManager(Actor actor) | |||
this.defaultTracker = new Dictionary<string, StateMetadata>(); | |||
} | |||
|
|||
public async Task AddStateAsync<T>(string stateName, T value, CancellationToken cancellationToken) | |||
public async Task AddStateAsync<T>(string stateName, T value, CancellationToken cancellationToken, int? ttlInSeconds) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to instead add an overload for when the TTL is specified:
AddStateAsync<T>(string stateName, T value, int ttlInSeconds)
rather than deviate from the .NET guidance that CancellationToken
be the last parameter of a method declaration. An exception exists to maintain backward compatibility with existing public APIs, but an overload would seem to provide the same effect while maintaining a consistent API.
Also, is it important for TTL to be specified in integer seconds as opposed to, say, a TimeSpan
, which might be more usable for larger values? (What do we expect the typical TTL to be?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @philliphoff! I'm brand new to .Net so please forgive my noob mistakes 😄 Can you take a look at my new changes to see if that is what you are after?
Also, is it important for TTL to be specified in integer seconds as opposed to, say, a TimeSpan, which might be more usable for larger values? (What do we expect the typical TTL to be?)
Indeed, TTL should be given as seconds as this matches what the Dapr API is expecting. What TTL to use is highly dependent on how long the app will be using the state for, but generally it should be set to "a bit more" than the expected usefulness of the key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. I was think more of the actual values used for TTLs. For example, the samples specify a TTL of 360
. Would that be better expressed as TimeSpan.FromMinutes(3)
so that users need not do the math (and potentially get it wrong), specially if they have much larger TTLs (e.g. hours/days).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, yes that makes sense I'll add that in.
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
/// <remarks> | ||
/// If null, the state will not expire. | ||
/// </remarks> | ||
public int? TTLInSeconds { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this conversion to seconds is only used in a single place (for the specific circumstances of the runtime API), would it make sense to move this logic there and only expose TTLExpireTime
? Is there value in exposing both to users of ActorStateChange
? (Especially since this property is a constantly changing value, being relative to the current date/time, which users may not expect from a property.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @philliphoff, I've updated the PR to only have hold the TTLExpireTime
value which gets converted to int seconds when saving the actor state.
change metadata Signed-off-by: joshvanl <[email protected]>
// Check if the property was marked as remove in the cache | ||
if (stateMetadata.ChangeKind == StateChangeKind.Remove) | ||
// Check if the property was marked as remove in the cache or is expired | ||
if (stateMetadata.ChangeKind == StateChangeKind.Remove || stateMetadata.TTLExpireTime <= DateTime.UtcNow) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: DateTimeOffset.UtcNow
(both here and elsewhere in the changes)?
I'm virtually certain that the built-in coersion between DateTime
and DateTimeOffset
make what's there equivalent, but perhaps best to use DateTimeOffset
as consistently as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also might be useful to keep a watch on .NET 8 which (finally) adds a means of abstracting time to simplify testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Done
public static StateMetadata Create<T>(T value, StateChangeKind changeKind) | ||
public DateTimeOffset? TTLExpireTime { get; set; } | ||
|
||
public static StateMetadata Create<T>(T value, StateChangeKind changeKind, DateTimeOffset? ttlExpireTime = null, TimeSpan? ttl = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the intent to have a method which allows a TTL, expiry time, or neither? If so, consider three methods, one which doesn't accept either, one that accepts the offset, and a third that accepts the time span. That would help ensure proper usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that makes sense- they are intended to be mutually exclusive. I've moved to using 3 functions.
@@ -132,6 +133,12 @@ private async Task DoStateChangesTransactionallyAsync(string actorType, string a | |||
writer.WritePropertyName("value"); | |||
JsonSerializer.Serialize(writer, stateChange.Value, stateChange.Type, jsonSerializerOptions); | |||
} | |||
|
|||
if (stateChange.TTLExpireTime.HasValue) { | |||
var ttl = (int)Math.Ceiling((stateChange.TTLExpireTime.Value - DateTime.UtcNow).TotalSeconds); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question, but is it spec'd to use the ceiling (vs. the floor or rounding) for TTLs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec is that it needs to be an integer value. It makes sense to me to be consistent in how we translate a fractional seconds. Rounding up a fractional second ensures that a value has a TTL of 1 second, rather than 0.
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1164 +/- ##
==========================================
+ Coverage 66.58% 68.47% +1.88%
==========================================
Files 171 172 +1
Lines 5752 5846 +94
Branches 628 648 +20
==========================================
+ Hits 3830 4003 +173
+ Misses 1772 1681 -91
- Partials 150 162 +12
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@philliphoff do you understand why the integration tests are failing? I'm not too sure what the problem is. |
Dunno. Maybe retry the job in case it was just a transient issue? |
@philliphoff Doesn't seem to be the case. Struggling to understand what is going wrong here.. at the limit of my .NET knowledge 😬 |
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Poked around this morning and found a couple of issues where existing state was ignored in favor of default values (see above suggestions), which were causing the E2E to fail. It might be good to add some unit tests for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs some changes (added as suggestion comments) in order to resolve E2E failure.
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Thank you @philliphoff, really appreciate your help with this! I've gone ahead and added those fixes, expanded the E2E state tests and added unit tests for those classed. Please take another look 🙂 |
Signed-off-by: joshvanl <[email protected]>
Hi @philliphoff, please let me know what you think when you have time |
* Actor state TTL support Signed-off-by: joshvanl <[email protected]> Signed-off-by: Divya Perumal <[email protected]>
Dapr Actor state TTL is a feature that was added in Dapr 1.12.
Adds support for Actor State TTL. TTL of actor state is set by using the
ttlInSeconds
metadata option when saving actor state. The actor state cache uses thettlExpireTime
return metadata field to determine whether the key is still valid, which is important as the cache may become populated withTTL
keys which were not created by the current manager.SDK developers are encouraged to use TTLs when storing any actor state in order to prevent stale data accumulating in the actor state store over time.
Closes #1164